Systems of Systems and Emergent System Context

One of the key issues facing architects of systems of systems (SOS) is the emergent nature of the context of the SOS. In the spirit of Herbert Simon, context here means all the stakeholders, objects, processes and other external effects that create the environment for goal attainment of a system. As SOS are systems, they too have contexts. Understanding the relationship between the contexts of the systems that constitute the SOS and SOS’s own context is a key step in building the architecture of a SOS. This paper will address SOS context from several perspectives. First, context is defined and examples given to explain its relevance to system architecture. This is followed by a discussion of how the context of an SOS is not simply the union of the contexts of its constituents, but rather emerges as a result of interactions that define the SOS. A key issue that arises from this view of SOS context is that the temporary nature of many SOS forces designers of constituent systems to be particularly adept at simultaneously operating in/planning for current, future and legacy SOS contexts in which they may be participating. The paper concludes with a discussion of different strategies for how constituent designers might handle this situation with recommendations and examples drawn from historical commercial and defense SOS. Introduction Since the mid 90’s there has been a growing interest in how systems come together to form systems of systems (SOS). These temporary coalitions of independently operated and managed systems can meet unforeseen needs in a timely and cost effective fashion. For example, during the first gulf war a SOS was formed between Patriot missile batteries and Defense Support Program (DSP) satellites. The satellites, meant for strategic missions, provided the Patriots’ operators with “over the horizon” early warning of medium-range missile launches prior to the inbound missiles being visible to the Patriot radar (Cunningham 1991). Combining disparate systems was not always so successful. During the lead up to the same conflict, electronic coordination could not be fully established with naval forces resulting in air tasking order needing to be flown from Riyadh out to aircraft carriers (Zinn 2004). There is much attention focused today on deliberately architecting systems so that they support broader objectives of a SOS. The first step is to identify those characteristics that distinguish the SOS engineering challenge from traditional systems engineering. Several authors have attempted such classification (e.g. Eisner 1991, Maier 1998, Keating 2003, Gideon 2005). Though there are differences in how each author defines the SOS problem, three key characteristics stand out in their definitions: 1. SOS are systems 2. SOS are composed of other systems that are value producing in their own right 3. SOS constituents have some sense of independence after being assembled into the SOS The first of these points indicates that SOS are systems and as such possesses the characteristics of systems traditionally cited such as stakeholders who build and derive value from their use, an environment in which they operate and, in the case of open systems, interfaces. The second point emphasizes that the constituents systems of a SOS are systems. They too possess the system characteristics outlined above. In joining the SOS the constituents do not lose their identity as systems and remain recognizable. The first two points alone, however, do not differentiate SOS as a class of systems requiring special attention – given these points, SOS are simply systems that happen to be composed of other systems. There are many systems that are composed of other systems. For example, a factory may be composed of several manufacturing cells, a mainframe of several processors, etc. The third point leads to the taxonomic distinction between SOS and the more general problem of systems engineering. Maier (1998) identifies two types of independence experienced by constituent systems: operational independence (if removed from the SOS, a constituent could operate once again as an independent system) and managerial independence (even when incorporated into the SOS, a constituent continues to deliver value independently). SOS that exhibit these two independence criteria are termed ‘collaborative SOS’ and, as Maier argues, require a different architectural approach than traditional systems. For example, in the Patrior-DSP case cited earlier, full command and control authority over the DSP satellites could not be handed over to the Patriot operators, as the DSP satellites still needed to perform other missions in addition to helping the Patriots. This paper focuses on collaborative SOS. The reader should take SOS to mean collaborative SOS unless otherwise stated. One key consequence of this independence is the complex nature of the environment or context in which a SOS operates. SOS being systems, exist within an environment. Their constituents are also systems and so also have a local environment. Given managerial independence, understanding the relationship between the SOS environment and the local environments of the constituents is important to creating successful SOS. This paper seeks to explore that relationship and discuss architectural issues that arise from it.